技術 Day 30：如果重來一次,參加鐵人賽這件事該怎麼跟 AI 協作——規劃階段的預期總結

前言 「都寫到最後一天了，不就該來一篇完整回顧 30 天的總結嗎？」 照風格慣例，Day 30 確實該是回顧整個系列、包含真實完賽心得的總結文。但誠實地說，這篇...

技術 Day 28：這套排程方法論的邊界——哪些情況它解決不了

前言 「前面 27 天講了這麼多排程、追蹤、品質守門的方法，聽起來已經很完整了，還有什麼是它解決不了的？」 任何方法論如果講到最後都變成「這個方法什麼都能解決」...

技術 Day 27：臨時加開系列的決定,現在回頭看值不值得

前言 「都寫到第 27 天了，這個臨時決定到底值不值得，總該有答案了吧？」 還沒有明確答案，因為完賽與否要等連續 30 天走完才能真正確認，現在下結論還太早。但...

技術 Day 25：案例——AI 建議的大綱結構,人為什麼要否決重排

前言 「AI 規劃的結構如果邏輯上說得通，為什麼還要人特地否決重排？」 「邏輯上說得通」是 AI 產出大綱時的預設狀態——因為 AI 本來就是順著給定的主題句和...

技術 Day 22：組隊挑戰跟單人挑戰在排程上的差異

前言 「組隊參賽不就是找幾個人一起報名，各自寫各自的文章嗎？排程上能有什麼不同？」 組隊挑戰確實不要求隊員寫同一個主題，賽制規則裡只要求隊員約定同一天開賽——但...

技術 Day 21：AI 能幫忙追蹤進度,但不能幫忙決定「今天要不要休息」

前言 「進度都靠自動化在追蹤了，乾脆連『今天該不該繼續』這個決定也交給系統判斷好了？」 進度追蹤是可以量化的事實問題——今天是第幾天、哪些系列已經發文、字數夠不...

技術 Day 20：多系列並行時,如果真的有一天來不及,退場方案要先想清楚

前言 「一定會遇到某一天來不及吧？那天實際上是怎麼處理的？」 老實說，寫到這篇為止，還沒有真的遇到某一天所有系列都來不及發文的情況——這系列的原則是不編造沒發生...

技術 Day 13：案例——一個技術主張查出來是對的,但呈現方式需要跟人討論

前言 「查核結果說『✅ 正確』,那不就代表這段內容沒問題,可以直接放著不用管了嗎？」 「正確」跟「呈現得好」是兩件事。一個技術主張可以在事實層面完全站得住腳，查...

技術 Day 12：客觀錯誤直接修、判斷空間大的先討論——這條界線怎麼畫

前言 「查核結果出來了,不管是什麼問題,直接照查核結果改掉不就好了？」 如果每個查核結果都直接照改，會出現一個問題：有些查核結果是「這句話講的規則有例外情況沒提...

技術 Day 15｜會議還在討論，Agent 已經把答案寫進正式系統

設計 Review 開到一半，畫面上同時放著三個方案。 目前設定是： Review Mode: Optional PM 問： 「如果改成 Review Req...

技術 Day 06：跟 AI 一起規劃 30 天大綱時,人要保留哪些判斷

前言 「大綱都讓 AI 生成了,那還有什麼是需要人保留的？」 Day 02 講過大綱規劃的粗略分工:人定主題句跟邊界、AI 拆解結構。這篇要把「人保留的判斷」講...

技術 Day 05：案例——報名最後一天,加開一個新系列的完整判斷過程

前言 「都報名最後一天了,乾脆別加了吧,風險這麼高幹嘛還要多做一個系列？」 這確實是一個合理的保守選項,而且在很多情況下應該是正確答案。這篇不是要說服你「臨時加...

技術 21. 當一切未知時，該如何做決策？

前言 當你是junior時，每次交給你一個任務你大概可以想像要怎麼樣達成目標，對於丟給你的問題，即使不知道要怎麼解，但你也大概有方向知道怎麼樣做是對的。然而世...